Skip to content

Attempt to update to FreeBSD 14.4.#23350

Open
LightBender wants to merge 3 commits into
dlang:masterfrom
LightBender:fix-freebsd
Open

Attempt to update to FreeBSD 14.4.#23350
LightBender wants to merge 3 commits into
dlang:masterfrom
LightBender:fix-freebsd

Conversation

@LightBender

Copy link
Copy Markdown
Contributor

No description provided.

@jmdavis

jmdavis commented Jul 3, 2026

Copy link
Copy Markdown
Member

It looks there are some warnings that need to be addressed due to changes that come with upgrading cross-platform-actions. But on top of that, it looks like there's a new test suite failure that I'm going to need to investigate.

I'm not seeing that failure locally on FreeBSD 15 (though I get an error from valgrind about it trying to use unimplemented functionality, which I haven't seen previously), but my laptop is still on FreeBSD 14 IIRC. So, I'll try to find time to try it there after I get some sleep.

@jmdavis

jmdavis commented Jul 4, 2026

Copy link
Copy Markdown
Member

I mentioned this to Adam elsewhere, but I'll mention it here for anyone else who might see the PR, but when I ran the test suite locally on my laptop with FreeBSD 14.3, it passed. I haven't tried 14.4 yet, because the drives proceeded to go south during that process, but since Adam has now tried this with FreeBSD 14.3, and it failed there too, that would indicate that it's not the case that 14.3 works and 14.4 does not. Presumably, either there is a difference in the environment, or I didn't run the tests in quite the same way. gmake test passed for me, and when I tried ci/run.sh test_dmd, it also passed, but it's possible that I passed a different set of environment variables (since it requires several) or values for them, and that's the difference. Given everything that is being done with the script, it's bit hard to know for sure given that I'm not about to run the full set of commands locally given that that would mess with the state of my machine - though maybe I could get a VM set up and try there, since then it wouldn't matter in the same way.

@Herringway

Copy link
Copy Markdown
Contributor

The CI logs point to a failure here: https://github.com/dlang/dmd/blob/master/compiler/test/dshell/dwarf.d#L57

I recall FreeBSD deprecating GCC in favour of LLVM in recent years. GNU's objdump puts the version on the first line, but LLVM's puts it on the second line -

GNU objdump (GNU Binutils) 2.46.0

vs

LLVM (http://llvm.org/):
  LLVM version 22.1.6

My guess is that objdump is LLVM's on the systems that are failing, and GNU's on the systems that aren't. Can you confirm?

@jmdavis

jmdavis commented Jul 4, 2026

Copy link
Copy Markdown
Member

The CI logs point to a failure here: https://github.com/dlang/dmd/blob/master/compiler/test/dshell/dwarf.d#L57

I recall FreeBSD deprecating GCC in favour of LLVM in recent years. GNU's objdump puts the version on the first line, but LLVM's puts it on the second line -

GNU objdump (GNU Binutils) 2.46.0

vs

LLVM (http://llvm.org/):
  LLVM version 22.1.6

My guess is that objdump is LLVM's on the systems that are failing, and GNU's on the systems that aren't. Can you confirm?

gcc was removed from FreeBSD some time ago and is only available via ports (IIRC because of the change to GPL v3), though I don't remember which version that was done in. That being said, it at least used to be the case that if you didn't have gcc installed, dmd wouldn't build.

Either way, on my FreeBSD 15 system, it looks like I have gcc and binutils installed (either because some port/package needed it, or I installed them with the assumption that I needed them to build dmd), so objdump is coming from binutils. I can't currently check on my laptop due to the drive failures, but I expect that it's the same, since I usually try to install the same packages when setting up a new system.

And if I put a symlink to /usr/bin/objdump (which would be the one that comes with the OS) in ~/bin so that it's the one that's used, then yes, that test fail. So, you probably identified the problem correctly. I don't know if that means that we should just require that binutils be installed to run the tests (in which case, we can likely just tweak the script here to install binutils) or whether the tests should be adjusted to be able to handle both cases.

@jmdavis

jmdavis commented Jul 4, 2026

Copy link
Copy Markdown
Member

I suspect that these changes missed something, since FreeBSD 13.2 x64, DMD (latest) is one of the pending jobs, whereas in theory, this should be replacing all of the FreeBSD 13.2 jobs with FreeBSD 14.3 or 14.4.

@jmdavis

jmdavis commented Jul 4, 2026

Copy link
Copy Markdown
Member

I don't know if that means that we should just require that binutils be installed to run the tests (in which case, we can likely just tweak the script here to install binutils) or whether the tests should be adjusted to be able to handle both cases.

LOL. Well, simply installing binutils isn't enough, since apparently, the default PATH order puts /usr/bin in front of /usr/local/bin (whereas for better or worse, I have my PATH set up so that /usr/local/bin is first). So, at this point, no one on FreeBSD is going to get the GNU version even if they have it installed unless they put extra effort into using it.

So, I guess that the options are

  1. Skip the objdump tests on FreeBSD (which would obviously not be ideal).
  2. Make it so that the tests explicitly use /usr/local/objdump on FreeBSD (and require that binutils be installed).
  3. Update the tests so that they work with both objdump -W and llvm-dwarfdump --all, which would be much more complicated, and it would require that llvm-dwarfdump be installed (which it isn't by default).

So, I think that I'll create a PR which does 2.

@jmdavis

jmdavis commented Jul 5, 2026

Copy link
Copy Markdown
Member

I suspect that these changes missed something, since FreeBSD 13.2 x64, DMD (latest) is one of the pending jobs, whereas in theory, this should be replacing all of the FreeBSD 13.2 jobs with FreeBSD 14.3 or 14.4.

Okay. If I understand correctly, that problem is caused by https://github.com/dlang/dmd/settings/branch_protection_rules/5665, so that will probably need to be changed after this is ready and merged, and if it blocks the merge, because it's marked is required, then we may have to force the merge first.

@jmdavis

jmdavis commented Jul 5, 2026

Copy link
Copy Markdown
Member

Okay. #23363 should fix the test failure. It turns out that FreeBSD 13 removed objdump entirely (so the test in question just got skipped, since it doesn't require that it pass, just that it pass if it's run), and the FreeBSD 14 added LLVMs objdump, which won't work with the tests. So, this wasn't failing in CI previously simply because the tests in question were skipped.

So, once that's merged, this should pass. However, the warnings caused by updating cross-platform-actions/action still need to be fixed

Warning: Input 'run' has been deprecated with message: The "run" parameter is deprecated. Use the custom shell (`shell: cpa.sh {0}`) on subsequent steps to run commands in the virtual machine instead.

Warning: Unexpected input(s) 'hypervisor', valid inputs are ['run', 'operating_system', 'architecture', 'version', 'shell', 'environment_variables', 'memory', 'cpu_count', 'image_url', 'sync_files', 'shutdown_vm']

and this should be switched back to FreeBSD 14.4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants